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Design Considerations for Faster-Than-Light (FTL) Communication 


Abstract 


We are approaching the time when we will be able to communicate 
faster than the speed of light. It is well known that as we approach 
the speed of light, time slows down. Logically, it is reasonable to 
assume that as we go faster than the speed of light, time will 
reverse. The major consequence of this for Internet protocols is 
that packets will arrive before they are sent. This will have a 
major impact on the way we design Internet protocols. This paper 
outlines some of the issues and suggests some directions for 
additional analysis of these issues. 
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Introduction 


We are approaching the time when we will be able to communicate 
faster than the speed of light. It is well known that as we approach 
the speed of light, time slows down. Logically, it is reasonable to 


a 


ssume that as we go faster than the speed of light, time will 


reverse. The major consequence of this for Internet protocols is 
that packets will arrive before they are sent. This will have a 
major impact on the way we design Internet protocols. This paper 
outlines some of the issues and suggests some directions for 
additional analysis of these issues. 


There is a lot of discussion in the physics community about faster- 
than-light travel and communication. In fact, it even has a well 
known acronym "FTL". This acronym will be used in the remainder of 
this document. 


FTL issues have been discussed in the scientific literature for a 
long time. For example, it was discussed in 1917 in the section 
"Velocities Greater than that of Light" on page 54 of "The Theory of 
the Relativity of Motion" [Tolman]. A good overall description of 
the effects of FTL communication can be found in [Goldberg]. 


[Ardavan] describes a "polarization synchrontron", which pushes radio 
waves faster than the speed of light. In the paper, the author 
explains: 


...-though no superluminal source of electromagnetic fields can be 
point-like, there are no physical principles preventing extended 
faster-than-light sources. The coordinated motion of aggregates 
of subluminally-moving charged particles can give rise to 
macroscopic polarization currents whose distribution patterns move 
superluminally. Further relevant progress occurred with the 
theoretical prediction that extended sources that move faster than 
their own waves could be responsible for the extreme properties of 
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both the electromagnetic emission from pulsars (rapidly spinning, 
magnetized neutron stars) and the acoustic emission by supersonic 
rotors and propellers. 


This may be a viable approach for transmitting data FTL. 
2. Protocol Design Considerations for FTL Communication 


Most, if not all, Internet protocols were designed with the basic 
assumption that the sender would transmit the packet before the 
receiver received it. For example, in the Transmission Control 
Protocol (TCP) [RFC0793], protocol activity is shown in timing 
diagrams such as Figure 7: 


TCP A TCP B 
1. CLOSED LISTEN 
2.  SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED 


3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED 
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED 
Basic 3-Way Handshake for Connection Synchronization 
Figure 7 of RFC 793 
In an FTL communication environment, this assumption is no longer 
true, because TCP B will receive the first SYN before TCP A 


transmitted it. For example, the first part of a TCP 3-way handshake 
in an FTL environment will look like: 


TCP A TCP B 
1. CLOSED LISTEN 
2. <SEQ=100><CTL=SYN> --> SYN-RECEIVED 
3. SYN-SENT --> <SEQ=100><CTL=SYN> 


The exact operation will depend on the difference between the 
backward time (i.e., from the future to the past) and the processing 
time to process a packet. If the processing time is greater than the 
backward time shift, then even though the packets are received out of 
order, TCP should still work due to the TCP symmetrical 3-way 
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handshake mechanism. If the processing time is smaller than the 
backward time shift, then it gets much harder, as many packets will 
be received before they are sent. The faster the communication is 
above the speed of light, the more severe the problem becomes. 


Assuming the first case where the processing time is equivalent or 
larger than the backward time shift (i.e., after an exchange of 
packets the backward time offset is canceled out), the TCP 3-way 
handshake in an FTL environment would look like: 


TCP A TCP B 
1. CLOSED LISTEN 
23 <SEQ=100><CTL=SYN> --> SYN-RECEIVED 
3. SYN-SENT --> <SEQ=100><CTL=SYN> 
4. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN, ACK> SYN-RECEIVED 
5. ESTABLISHED <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 
6. ESTABLISHED <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED 
7. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> ESTABLISHED 


It shows remarkable forethought by the inventors of the TCP protocol 
that the 3-way handshake works in an FTL communication environment. 
This is due to the symmetrical nature of the 3-way handshake and its 
ability to deal with dropped packets. It should be possible to use 
dropped packets as a way to mimic an FTL communication environment. 
In fact, this may provide a good vehicle to analyze and test 
protocols to see how they will work in an FTL communication 
environment. 


2.1. Related Issues 


Additional work is needed to think about protocol design 
considerations when the backward time shift is much greater than the 
processing time. This would create challenges where it would be 
necessary to have received all of the data before the connection 
could be established. This is left to future researchers. In 
practical terms, this scenario isn’t likely to happen for a long 
time. That said, FTL communication might lead to FTL travel, where 
we can travel into the past. It may be necessary to start working on 
this yesterday. 
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There is a large amount of work that has been done in a related area, 
Delay-Tolerant Networks. For example, [RFC4838] defines an 
architecture for Delay-Tolerant Networks. An FTL communication 
environment is similar to Delay-Tolerant Networks with the major 
difference that the packets arrive at the destination with a negative 
delay. Documents that will need review include "A One-way Delay 
Metric for IPPM" [RFC2679] and "A Delay Bound alternative revision of 
RFC 2598" [RFC3248]. 


Congestion control algorithms will also need serious review -- 
specifically, how to handle negative round-trip time (RTT) on TCP 
congestion control or the corner case where the RIT comes out at 
exactly zero. Do any of the control equations include a divide-by- 
RTT or sqrt (RTT)? It should also be noted that there may be the 
possibility for significant advancements in congestion algorithms 
given the properties of FTL communication. Specifically, it maybe 
possible to stop network congestion before it starts. This could be 
an important new approach for congestion control researchers. 


3. FTL Communication Research 


FTL communication has great potential for the networking research 
community. It is clearly an exciting area for new research and 
considerable time could be spent working on it. It is very important 
that we fully understand all of its aspects before we know how to 
achieve FTL communication. Funding agencies should take this into 
account when allocating money and make sure that all new research 
projects look at FTL communication environments. 


4. IETF Recommendations 


The Internet Engineering Steering Group (IESG), which is the part of 
Internet Engineering Task Force (IETF) that manages the standards 
process, has area reviews as part of its review process. For 
example, the Security area reviews proposed protocols for security 
issues. The IETF Chair also has a General area that does overall 
reviews. 


The author recommends that the IETF create a new review group to 
evaluate all new Internet protocols to verify that FTL communication 
has been taken into consideration in the design of the protocol. 
This would be similar to what is done to make sure that new Internet 
protocols are secure or are designed to run over IPv4 and IPv6. As 
we look forward to FTL communication, it is critical that all 
Internet protocols are designed to work in this environment. 
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Further, the author recommends that the IESG start a review process 
to do a detailed analysis of all existing Internet protocols to make 
sure they have been designed to work in FTL communication 
environments. For protocols that do not work in this environment, 
the IESG should add work items to exiting working group charters or 
charter new working groups to update these protocols so that they 
will work in FTL communication environments. 


5. Security Considerations 


It is early to fully understand security issues relating to FTL 
communication. The main issue is likely to be related to the 
characteristic of FTL communication that the receiver will receive a 
packet before it is sent. Many exploits are likely to be written to 
take advantage of this property. Also, given the number of exploits 
that are being discovered that don’t have any protections available, 
it may be that the malware community is already taking advantage of 
the properties of FTL communication. 
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